Testaussuunnitelma

PDM-ryhmä
EAT-projekti

Muutoshistoria
Editoija Päivämäärä Versio Muutokset
Miiku Jaakkola 24.10.2000 0.1 Ensimmäinen versio
Timo Ratilainen 26.10.2000 0.2 Pieniä korjauksia
Miiku Jaakkola 2.11.2000 0.3 Muutoksia ja tarkennuksia
Miiku Jaakkola 5.11.2000 0.4 Viimeistelyä, korjauksia
Timo Ratilainen 6.11.2000 1.0 Katselmoinnin korjaukset
Miiku Jaakkola 10.12.2000 1.1 T2-vaiheen muutokset, muutokset löytyvät kappaleesta 1.1
Timo Ratilainen 11.12.2000 2.0 Katselmoinnin korjaukset
Miiku Jaakkola 18.4.2001 2.1 LU-vaiheen muutokset, muutokset löytyvät kappaleesta 1.1
Timo Ratilainen 20.3.2001 2.2 Termiluettelo aakkosjärjestykseen
Miiku Jaakkola 23.4.2001 2.3 Katselmoinnni korjaukset
Timo Ratilainen 23.4.2001 3.0 Hyväksytty versio.

 
Katselmointi
Katselmoija(t) Päivämäärä Versio Hyväksyjä
Timo Ratilainen, Miiku Jaakkola, Tero Kilkanen, Jukka Hynninen, Anssi Keskinen, Jaakko Tuomimäki 6.11.2000 1.0 Timo Ratilainen
Timo Ratilainen, Miiku Jaakkola, Tero Kilkanen, Jukka Hynninen, Jaakko Tuomimäki 11.12.2000 2.0 Timo Ratilainen
Timo Ratilainen, Miiku Jaakkola, Tero Kilkanen, Jukka Hynninen, Jonne Loikkanen, Anssi Keskinen, Jaakko Tuomimäki 23.4.2001 3.0 Timo Ratilainen

Tiivistelmä

Tämä dokumentti on PDM-ryhmän testisuunnitelma EAT-työkalun testausprosessille.

Sisällysluettelo

1. Johdanto

1.1 Viime vaiheen jälkeen tehdyt muutokset
1.2 Tarkoitus ja kattavuus

1.3 Tuote ja ympäristö

1.4 Määritelmät, termit ja lyhenteet

1.5 Viitteet

2. Ympäristövaatimukset
2.1 Laitteisto

2.2 Ohjelmisto

2.3 Turvallisuus

2.4 Apuvälineet

3. Henkilöstö- ja koulutusvaatimukset
3.1 Henkilöstö

3.2 Koulutus

4. Vastuualueet
4.1 Modulitestaus

4.2 Integrointitestausryhmä

4.3 Järjestelmätestausryhmä

4.4 Käytettävyystestausryhmä

5. Vaadittava tulosaineisto
5.1 Modulitestaus

5.2 Integrointitestaus

5.3 Järjestelmätestaus

5.4 Käytettävyystestaus

6. Testattavat toiminnot
6.1 Testattavat modulit

6.2 Ohjelmaan liittyvät toiset toiminnot

6.3 Käyttäjän toiminnot

6.4 Operaattorin toiminnot

7. Erikoisominaisuuksia
7.1 Ominaisuudet joita ei testata

7.2 Ominaisuudet jotka testataan

8. Testauksen tehtäväjärjestys
8.1 Testitapausluokat

8.1 Modulitestaus

8.2 Integrointitestaus

8.3 Järjestelmätestaus

8.4 Käytettävyystestaus

9. Testausmenettely ja testaustapaukset
9.1 Menetelmät ja tekniikat

9.2 Kattavuus

9.3 Rajoitukset

9.4 Ohjelmaan liittyvien osien testaus

9.5 Käyttöliittymän testaus

9.6 Liittymien testaus

9.7 Turvallisuuden testaus

9.8 Toipumisen (elpymisen) testaus

9.9 Suorituskykytestaus

9.10 Regressiotestaus

10. Testin hyväksymis- ja hylkäämiskriteerit
10.1 Hyväksymiskriteerit

10.2 Hylkäämiskriteerit

10.3 Vaatimukset testauksen keskeyttämiselle

10.4 Vaatimukset testauksen jatkamiselle

10.5 Vaatimukset testauksen lopettamiselle

11. Riskien hallinta

12. Aikataulu

13. Hyväksyjät

13.1 Testit ja testitapaukset

13.2 Koko testaus

Lähdeluettelo
 

1. Johdanto

1.1 Viime vaiheen jälkeen tehdyt muutokset

Kappaletta 1.2 (Tarkoitus ja kattavuus) on päivitetty. Kappaletta 1.5 (Viitteet) on päivitetty. Kappaletta 5.2 (Integrointitestaus) on päivitetty. Kappaletta 5.3 (Järjestelmätestaus) on päivitetty. Kappaletta 6 (Testattavat toiminnot) on päivitetty. Kappaletta 9.1 (Menetelmät ja tekniikat) on päivitetty. Kappaletta 9.6 (Liittymien testaus) on päivitetty. Kappaletta 9.10 (Regressiotestaus) on päivitetty. Kappaletta 12 (Aikataulu) on päivitetty.
 

1.2 Tarkoitus ja kattavuus

Tämä dokumentti on EAT-työkalun testausuunnitelma..

Tässä dokumentissa käsitellään korkeamman tason integrointi- ja järjestelmätestausta. Modulitestaus tehdään itsenäisesti koodauksen yhteydessä ja siitä laaditaan erillinen testausraportti kullekin modulille. Käytettävyystestauksella pyritään varmistamaan tuotteen käytettävyys. Tätä varten on laadittu erillinen käytettävyystestaussuunnitelma.

Varsinaiset integrointi- ja järjestelmätestauksen testitapaukset määritellään erillisessä dokumentissa.
 
 
 

1.3 Tuote ja ympäristö

EAT (EDMS Administrator's Tool) on EDMS-dokumenttien hallintajärjestelmän ylläpitäjän graafinen työkalu, joka suunnitellaan ja toteutetaan harjoitustyöprojektina Teknillisen Korkeakoulun Tik-76.115 Tietojenkäsittelyopin ohjelmatyö-kurssilla. Työkalu tehdään Javalla ja se kommunikoi TCP/IP-yhteyden yli EDMS-palvelimen kanssa käyttäen valmiiksi määriteltyä protokollaa, jolla ylläpitokomennot välitetään. Työ tehdään TAI-tutkimuslaitokselle, työn asiakas on Asko Martio ja ohjaaja on Hannu Peltonen.
 
 

1.4 Määritelmät, termit ja lyhenteet

 
Black box-testaus Testausmenetelmä, jossa testaaja ei oleta mitään testattavan ohjelman rakenteesta vaan testaa ohjelmaa vain ohjelman rajapintamäärittelyiden perusteella.
Burana Virhe- ja kokoraportointijärjestelmä joka tarjotaan projektiryhmän käyttöön Ohjelmatyö-kurssin puolesta.
EAT EDMS Administrator's Tool, on projektin lopputuloksena saatavan ohjelmiston(+dokumentaatio) nimi.
EDMS Engineering Data Management System, PDMG-ryhmän toteuttama tuotetiedon hallintajärjestelmä.
Integrointitestaus Integrointitestauksessa testataan miten modulit toimivat yhteen ja järjestelmän toimintaa kokonaisuutena.
Järjestelmätestaus Järjestelmätestauksessa testataan, toteuttaako järjestelmä sille asetetut vaatimukset.
Käytettävyystestaus Käytettävyystestauksessa testataan ja kehitetään testattavan ohjelman käytettävyyttä.
Modulitestaus Modulitestauksessa testataan itsenäisen ohjelman osan, modulin, toimintaa.
PDMG Product Data Management Group on TAI-tutkimuslaitoksessa toimiva tuotetiedon hallintaa tutkiva ryhmä.
Tirana Tuntiraportointijärjestlmä joka tarjotaan projektiryhmän käyttöön Ohjelmatyö-kurssin puolesta.
ViCa Visualization Client Application on visualisointityökalu Tirana-järjestelmällä syötettyyn tietoon.
White box-testaus Testausmenetelmä, jossa testaaja tuntee testattavan ohjelman rakenteen ja tekee testinsä tähän tietoon pohjautuen.

 

1.5 Viitteet

Projektisuunnitelma (LU)
Laatusuunnitelma (T2)
Vaatimusmäärittely (LU)
Käytettävyystestaussuunnitelma (LU)
Moduulitestiraporttipohja
Toiminnallinen määrittely (T2)
Technical specification (T2)
Testitapausten lista (LU)
 
 

2. Ympäristövaatimukset

2.1 Laitteisto

Moderni laitteisto, josta on yhteys EDMS-palvelimelle. EDMS-palvelin ei saa olla samassa koneessa testilaitteiston kanssa.
 
 

2.2 Ohjelmisto

Pääasiallinen testausalusta Windows, jossa JDK 1.2 ja JRE; myös muita JRE-järjestelmiä testataan siirrettävyysvaatimuksien takia. Testausympäristössä on oltava yhteys EDMS-palvelimelle, johon tehdään testitietokanta.
 
 

2.3 Turvallisuus

Turvallisuustestauksen tarpeellisuutta on harkittu. Koska tietoliikennekomponentti saadaan uudelleenkäyttämällä aiemman projektin koodia, sitä ei testata Usean ylläpitäjän yhtäaikainen käyttö ja sen mahdollisesti aiheuttamat ongelmat testataan.
 
 

2.4 Apuvälineet

Testauksen aikana tarvittavat testiajurit, stubit ym. selvitetään testausympäristön suunnittelun ja toteutuksen aikana.
 
 

3. Henkilöstö- ja koulutusvaatimukset

3.1 Henkilöstö

Käytettävyystestauksessa tarvitaan projektiryhmän ulkopuolisia testihenkilöitä, jotka saadaan asiakkaalta.
 
 

3.2 Koulutus

Käytettävyystestin testihenkilöiden tulee tuntea EDMS-peruskäsitteet jotta he voivat tehdä annettuja tehtäviä ja jotta tehtävien tekoprosessi on mahdollisimman realistinen eli vastaa tuotteen käyttäjien tehtävien tekoprosessia.
 
 

4. Vastuualueet

4.1 Modulitestaus

Kunkin modulin toteuttaja on vastuussa kyseisen modulin testauksesta.
 
 

4.2 Integrointitestausryhmä

Testausvastaava on vastuussa integrointitestauksesta.
 
 

4.3 Järjestelmätestausryhmä

Testausvastaava on vastuussa järjestelmätestauksesta.
 
 

4.4 Käytettävyystestausryhmä

Käyttöliittymävastaava ja testausvastaava ovat vastuussa käytettävyystestauksesta.
 
 

5. Vaadittava tulosaineisto

Jokaista ajettavaa testiä varten tehdään testaussuunnitelma ja tuloksista tehdään testausraportti.  Testaussuunnitelmien tulisi olla riittävän tarkkoja, jotta testit voidaan niiden perusteella tarvittaessa toistaa. Jos ja kun testejä joudutaan ajamaan useamman kerran, testiraportteja voidaan luonnollisesti yhdistää samaan dokumenttiin.

Testauksessa havaittavat bugit raportoidaan Burana-järjestelmällä.
 
 

5.1 Modulitestaus

Modulitesteistä tehdään testausraportti. Raportissa on selvitettävä, mitä on testattu ja jos ei, miksi ei modulitestiraporttipohjan mukaisesti.
 

5.2 Integrointitestaus

Modulien integrointitestausta varten tehdään testaussuunnitelma, jossa on kuvattu käytettävät testiajurit, testitapaukset ja testiohjeet. Testitapauksista merkitään myös, mitä teknisen suunnitelman toimintoa testataan. Aikataulusyistä integrointitestaus yhdistetään järjestelmätestaukseen.

Jokaisesta suoritetusta testistä tehdään testausraportti. Raportissa on oltava kaikki ajetut testitapaukset ja havaitut virheet. Raportissa on myös ilmoitettava, hyväksyttiinkö kyseinen testi.
 
 

5.3 Järjestelmätestaus

Järjestelmätestausta varten tehdään testaussuunnitelma, jossa on kuvattu testitapaukset ja miten ne suoritetaan. Testeistä tehdään testausraportti, jossa on oltava havaitut virheet.
 
 
 

5.4 Käytettävyystestaus

Käytettävyystestausta varten tehdään testaussuunnitelma ja testituloksista kirjoitetaan testausraportti.
 
 

6. Testattavat toiminnot

 

6.1 Testattavat modulit

Järjestelmän rakenne on kuvattu teknisessä määrittelyssä (technical specification). Testattavia moduleita on kolme: GUI, Pinjainterface ja Pinja-laajennukset. Testattavat moduliversiot ilmoitetaan kunkin testauskerran testaussuunnitelman yhteydessä.
 
 

6.2 Ohjelmaan liittyvät toiset ohjelmat

Projektissa testataan vain tehtävää ylläpitäjän työkalua. Muita järjestelmän osia ei testata, mukaanlukien aiemmista projekteista saatava, uudelleenkäytettävä koodi.
 
 

6.3 Käyttäjän toiminnot

Testattavat käyttäjän toiminnot saadaan vaatimusmäärittelystä ja ne testataan järjestelmätestauksen aikana.
 
 

7. Erikoisominaisuuksia

7.1 Ominaisuudet joita ei testata

Aiemmista projekteista saatavia uudelleenkäytettäviä komponentteja ei testata. Suorituskykyä testataan siinä määrin järjestelmätestauksen yhteydessä, että saadaan selville toimiiko järjestelmä järkevän nopeasti.
 
 

7.2 Ominaisuudet joita testataan

Testattavat ominaisuudet määritellään toiminnallisessa määrittelyssä kappaleessa 4.2 (Järjestelmän toiminnot).
 

8. Testauksen tehtäväjärjestys

Testauksessa edetään siten, että aloitetaan modulitestauksella ja edetään modulien integrointitestauksen kautta järjestelmätestaukseen. Käytettävyystestaus aloitetaan mahdollisimman aikaisessa vaiheessa, viimeistään siinä vaiheessa kun saadaan ensimmäinen prototyyppi toimivaksi.

Kullakin testityypillä on omat hyväksymiskriteerit, jotka on saavutettava jotta testaus tältä osin voidaan hyväksyä suoritetuksi. Integrointi- ja järjestelmätestauksella on myös testauksen aloituskriteerit, joiden on täytyttävä jotta tämä testausvaihe voidaan aloittaa.
 

8.1 Testitapausluokat

Testitapaukset jaetaan kolmeen tärkeysluokkaan: 1, 2 ja 3. Luokan 1 ja 2 testit on ajettava uudelleen bugien korjauksen jälkeen, jos ne eivät mene läpi.
 
 
Luokka Vakavuus ja kuvaus Testattava uudelleen
1 Vakava. Ohjelma kaatuu tai jumiutuu. Kyllä
2 Keskimääräinen. Ohjelman toiminnallisuudet eivät toimi, tuottavat virheellisen tuloksen tai niiden käyttäminen on liian vaikeaa/hidasta. Kyllä
3 Kosmeettinen. Ei vaikuta ratkaisevasti ohjelman toimintojen käyttämiseen (esimerkiksi kirjoitusvirheet). Ei

 

8.2 Modulitestaus

Hyväksymiskriteerit: Modulitestit on saatu ajettua testisuunnitelman mukaisesti, tärkeysluokan 1 bugeja ei ole auki.
 
 

8.3 Integrointitestaus

Aloituskriteerit: Modulitestauksen hyväksymiskriteerit.

Hyväksymiskriteerit: Integrointitestauksen testit on saatu ajettua testisuunnitelman mukaisesti ja tärkeysluokan 1 bugeja ei ole auki.
 
 

8.4 Järjestelmätestaus

Aloituskriteerit: Integrointitestauksen hyväksymiskriteerit.

Hyväksymiskriteerit: Regressiotestaus menee läpi, järjestelmätestauksen testitapaukset on käyty läpi ja testit on hyväksytty ja korjaamatta on vain kosmeettisia (tärkeysluokan 3) bugeja.
 
 

8.5 Käytettävyystestaus

Hyväksymiskriteerit: Testaussuunnitelman mukaiset käytettävyystestit on saatu ajettua, järjestelmän käytettävyys on hyväksyttävällä tasolla.
 
 

9. Testausmenettely ja testaustapaukset

9.1 Menetelmät ja tekniikat

Modulitestauksessa alunperin käytettäviksi suunnitelluista automatisoiduista testeistä on luovuttu. Modulitestauksessa käytetään white box-testausta siten, että jokainen modulin kirjoittaja testaa oman modulinsa siten, että mahdollisimman suuri osa koodiriveistä käydään läpi. Modulitesteistä kirjoitetaan testiraportit.

Integrointitestauksessa kirjoitetaan tarpeen mukaan testiajureita, jotka syöttävät dataa järjestelmään. Black box-testauksella käydään läpi testitapaukset. Integrointitestaus yhdistetään järjestelmätestaukseen aikataulusyistä.

Järjestelmätestauksessa testataan miten koko järjestelmä toimii ja toimiiko se käyttäjän vaatimusten mukaisesti. Funktionaalisten ominaisuuksien testauksen jälkeen siirrytään testaamaan siirrettävyyttä ja ylläpidettävyyttä sekä suorituskykyä.

Käytettävyystestauksessa järjestetään testihenkilöillä mahdollisimman aikaisesta vaiheesta lähtien käytettävyystestejä, mahdollisesti paperiprotoja käyttäen. Käytettävyystestejä tehdään jatkuvasti projektin kuluessa. Mahdollisesti käytettäviä menetelmiä ovat ainakin projektin jäsenien tekemät heuristiset läpikäynnit.
 
 

9.2 Kattavuus

Jokainen teknisessä määrittelyssä oleva toiminto testataan vähintään kerran. Jokainen vaatimusmäärittelyssä oleva toiminto testataan vähintään kerran. Koodissa metodien raja-arvojen testaukseen kiinnitetään erityistä huomiota.
 

9.3 Rajoitukset

Käytettävyystestit tulee suunnitella testihenkilöiden aikataulun mukaisesti.
 
 

9.4 Ohjelmaan liittyvien osien testaus

Ohjelmaan projektin ulkopuolelta liittyviä osia, kuten esimerkiksi EDMS-palvelinta, ei testata.
 
 

9.5 Käyttöliittymän testaus

Käyttöliittymätestauksesta on tehty erillinen käyttöliittymätestaussuunnitelma.
 

9.6 Liittymien testaus

Liittymät testataan modulitestauksen yhteydessä.
 
 

9.7 Turvallisuuden testaus

Turvallisuuden testausta tarvitaan lähinnä testattaessa salattua verkkoyhteyttä EDMS-palvelimelle. Koska tämä komponentti on jo toteutettu aiemmassa projektissa, ei testausta tehdä.
 
 

9.8 Toipumisen (elpymisen) testaus

Testataan ainakin tilannetta, jossa verkkoyhteys EDMS-palvelimelle on poikki.
 
 

9.9 Suorituskyvyn testaus

Testataan, että järjestelmä on tarpeeksi nopea ollakseen käytettävä. Suorituskykytesteissä voidaan mahdollisesti käyttää olemassaolevaa dokumenttitietokantaa. Jos tämä ei onnistu, testausympäristöä toteutettaessa tehdään myös laaja dokumenttitietokanta EDMS-palvelimelle.
 
 

9.10 Regressiotestaus

Järjestelmätestauksen ohessa tehdään vakiotesti, jolla testataan etteivät tehdyt muutokset ole aiheuttaneet ei-haluttuja muutoksia toiminnallisuudessa. Regressiotestaus ajetaan muutoksien jälkeen ja ainakin kerran kunkin projektin vaiheen aikana. Testi on ajettava viimeistään 3-7 päivää ennen vaiheen deadlineä.
 
 

10. Testin hyväksymis- ja hylkäämiskriteerit

10.1 Hyväksymiskriteerit

Testi hyväksytään, jos tärkeysluokan 1 ja 2 testit saadaan läpi ja vähintään 90% kaikista testeistä menee läpi.
 
 

10.2 Hylkäämiskriteerit

Testi hylätään, jos hyväksymiskriteerit eivät täyty.
 
 

10.3 Vaatimukset testauksen keskeyttämiselle

Testaus keskeytetään, jos kriittinen järjestelmän osa, kuten esimerkiksi tietoliikenneyhteys EDMS-palvelimelle, ei toimi.
 
 

10.4 Vaatimukset testauksen jatkamiselle

Jatkettaessa keskeytynyttä testausta tärkeysluokan 1 testit on suoritettava uudestaan. Tärkeysluokkien 2 ja 3 jo läpimenneitä testejä ei tarvitse suorittaa uudelleen jatkettaessa keskeytynyttä testausta.
 
 

10.5 Vaatimukset testauksen lopettamiselle

Testaus voidaan lopettaa, kun moduli-, integrointi-, järjestelmä- ja käytettävyystestauksen hyväksymiskriteerit täyttyvät.
 
 

11. Riskien hallinta

Riskeissä on määritelty itse riski, sen havainnointi, syy, seuraus, ehkäisy ja reagointi. Riskit ovat arvioidussa vakavuusjärjestyksessä vakavimmasta vähiten vakavaan.
 
Riski Havainnointi Syy Seuraus Ehkäisy Reagointi
Ohjelma ei valmistu ajoissa testaukseen Projektipäällikkö seuraa koodauksen edistymistä, koodaajat ilmoittavat ongelmistaan, testausta aloitettaessa ohjelma ei toimi lainkaan. Inhimilliset syyt, huono suunnittelu, kommunikaatio pettää. Joudutaan testaamaan liikkuvaa maalia, testausaikataulu pettää. Laaditaan testaussuunnitelma huolella yhdessä muun projektin aikataulutuksen kanssa. Lisäresursseja koodin ongelmakohtiin.
Testausaikataulu pettää Bugeja löytyy aina vain lisää vaikka deadline lähestyy, deadlinet missataan. Huono suunnittelu, koodin huono laatu, kommunikaatio pettää. Ohjelman testausta ei saada tehtyä ajoissa Laaditaan testaussuunnitelma huolella yhdessä muun projektin aikataulutuksen kanssa. Lisäresursseja testaukseen, kun käy ilmi aikataulun pettäminen.
Testausympäristö ei toimi Testausympäristön toteutus jää aikataulusta jälkeen, testausympäristöä kokeiltaessa se ei toimi, testauksen aikana testausympäristö lakkaa toimimasta tai ei toimi lainkaan. Huono suunnittelu, ennalta-arvaamattomat syyt kuten muutokset asiakkaan firewalleissa. Testaus ei onnistu, testausaikataulu pettää. Testausvastaava suunnittelee ja huolehtii yhdessä järjestelmävastaavan kanssa testausympäristöstä. Laitetaan lisäresursseja testausympäristön korjaamiseen ja mahdollisesti testaukseen.
Asiakas ei pysty toimittamaan käytettävyystestihenkilöjä Kysytään asiakkaalta testihenkilöistä. Käytettävyystestien aikataulut eivät sovi mahdollisille testihenkilöille, kommunikaatio asiakkaan kanssa pettää.  Käytettävyystestaus kärsii. Ei tehdä käytettävyystestausta pelkästään riippuvaiseksi testihenkilöistä. Tehdään käytettävyystestausta asiantuntijamenetelmillä, esim. heuristisilla läpikäynneillä. Pyritään hankkimaan testihenkilöitä muualta.

 

12. Aikataulu

Etapit kurssin palautusten mukaisesti siten, että vaiheessa tehtävä testaus saadaan tehtyä vähintään kolme päivää ennen palautuksen deadlineä.
 
 
Vaihe Tehtävät
T1 -
T2 Testaussuunnitelman tarkennus, modulitestaus alkaa, käytettävyystestaus alkaa, testausympäristön suunnittelu ja toteutus alkaa
T3 Modulitestaus saadaan hyväksyttyä, käytettävyystestaus jatkuu, testausympäristö saadaan toteutettua, integrointitestaus alkaa
T4 Integrointitestaus saadaan hyväksyttyä, käytettävyystestaus jatkuu, järjestelmätestaus alkaa
LU Käytettävyystestaus saadaan hyväksyttyä, järjestelmätestaus saadaan hyväksyttyä

 
 

13. Hyväksyjät

13.1 Testit ja testitapaukset

Suoritetut testit voi hyväksyä testausvastaava tai projektipäällikkö.
 
 

13.2 Koko testaus

Koko testauksen hyväksymiseksi tulee projektipäällikön, testausvastaavan ja laatuvastaavan hyväksyä testaus.